…_name_span`

This method's main responsibility is to flush the pending dups into refined
spans, if appropriate.

…ing_dups`

This patch also sorts the constructor fields into declaration order.

It turns out that all of the `len` manipulation here was just reimplementing
`last_mut`.

This span can always be retrieved from `prev`, so there is no need to store it
separately.

This makes it easier to see that the non-initial cases assume that `prev` and
`curr` are set, and all operate on the same prev/curr references.

This reduces clutter, and makes it easier to notice regions where mutations
definitely don't occur.

Interacting with `basic_coverage_blocks` directly makes it easier to satisfy
the borrow checker when mutating `pending_dups` while reading other fields.

This makes it so that all the matchers that match against paths use the
definition path instead of the export path. This removes all duplication
around `std`/`alloc`/`core`.

This is not necessarily optimal because we now depend on internal
implementation details like `core::ops::control_flow::ControlFlow`,
which is not very nice and probably not acceptable for a stable
`on_unimplemented`.

An alternative would be to just string-replace normalize away
`alloc`/`core` to `std` as a special case, keeping the export paths but
making it so that we're still fully standard library flavor agnostic.

…ng AST

coverage: Several small cleanups in `spans`

While investigating the details of coverage span processing, I noticed several opportunities to make the code simpler and clearer.

---

`@rustbot` label +A-code-coverage

…cleanup, r=notriddle

Improve display of parallel jobs in rustdoc-gui tester script

If no `-j` option is not passed to `x.py`, it would display `-1`, which isn't great.

r? `@notriddle`

…s, r=jackh726

Fix implied outlives check for GAT in RPITIT

We enforce certain `Self: 'lt` bounds for GATs to save space for more sophisticated implied bounds, but those currently operate on the HIR. Code was easily reworked to operate on def-ids so that we can properly let these suggestions propagate through synthetic associated types like RPITITs and AFITs.

r? `@jackh726` or `@aliemjay`

Fixes rust-lang#116789

…-alloc-whatever-who-cares, r=compiler-errors

Make `rustc_onunimplemented` export path agnostic

This makes it so that all the matchers that match against paths use the definition path instead of the export path. This removes all duplication around `std`/`alloc`/`core`.

This is not necessarily optimal because we now depend on internal implementation details like `core::ops::control_flow::ControlFlow`, which is not very nice and probably not acceptable for a stable `on_unimplemented`.

An alternative would be to just string-replace normalize away `alloc`/`core` to `std` as a special case, keeping the export paths but making it so that we're still fully standard library flavor agnostic.

Looking at the diff, I'm starting to think that some simple string replacement would go a long way towards fixing the problem of duplication while keeping export paths...

What do you prefer?

Also `@weiznich` for your thoughts about the stable version.

r? compiler-errors

…trieb

Add myself to smir triage

I would like get pinged when someone makes changes to smir

…-format-string-literal, r=Nilstrieb

Preserve unicode escapes in format string literals when pretty-printing AST

Fixes rust-lang#116799

Thanks to `@Nilstrieb` for the pointer to the correct location, that was really helpful for someone unfamiliar with the codebase.